# Prompt pour Claude FACTIZY — brancher le mode test (compatible ERP)

_Rédigé le 26-09-26 à partir du code et de la base réels de l'ERP CTIERP._

---

Contexte : FACTIZY (`erp/FACTIZY/`) partage la base MariaDB `cloud` avec l'ERP CTIERP (`erp/`), et aussi avec Nextcloud (tables `oc_*`).
Il faut brancher le **« mode test »** dans FACTIZY, de façon compatible avec celui de l'ERP. Pas de question de clarification : fais des choix raisonnables et annonce-les.

## Comment l'ERP fait déjà le mode test (à reprendre tel quel, ne rien réinventer)

- **Marquage par triggers MariaDB `BEFORE INSERT`** : chaque ligne créée reçoit `test_date_heure = NOW()` et `test_id_user = <id utilisateur>`, mais seulement quand la connexion a fait `SET @cti_test_user = <id>`. Sans ça, la variable reste `NULL` et rien n'est marqué.
- Les colonnes `test_date_heure` (datetime NULL) et `test_id_user` (int NULL) **EXISTENT DÉJÀ** sur les 51 tables `factures_*`. Ne fais **aucun** `ALTER TABLE`.
- Les triggers sont dans `D:\TRAVAIL\CTI-Ouest\mode_test_triggers.sql`. Constat du 26-09-26 : ils **ne sont pas encore installés** (0 trigger dans la base). C'est l'utilisateur qui les lance. FACTIZY ne doit pas créer de trigger lui-même.
- Côté ERP (`erp/system/acces.php`) :
  - le mode test est actif si `$_SESSION['1cti_mode_test']` est non vide (préfixe `$particule = "1cti_"`)
  - **ET** si l'utilisateur a le droit spécifique `testeur` ou `testeur_factizy` : table `users_pages` (colonnes `id_user`, `cle`). L'utilisateur id=1 (développeur) a tous les droits d'office.
  - Ensuite `mode_test_appliquer()` fait `SET @cti_test_user=<id>` (ou `=NULL`) sur la connexion.
- La bascule se fait en ajax : `erp/ajax/mode_test.php` (POST `valeur=1|0`, positionne `$_SESSION['1cti_mode_test']`). Pied de page ERP : bandeau rouge « MODE TESTEUR » + interrupteur.
- La purge est faite par l'ERP : `?page=mode_test_purge` (droit testeur). Elle liste via `information_schema` les tables qui ont `test_id_user`, `factures_*` comprises, puis `DELETE ... WHERE test_id_user IS NOT NULL`. **FACTIZY n'a pas besoin de sa propre purge.**

## Ce qu'il faut faire dans FACTIZY

1. **Activer le marquage sur CHAQUE connexion FACTIZY** (`FACTIZY/system/connect.php`, juste après `mysqli_connect`, pour couvrir pages, ajax et actions) : `SET @cti_test_user=<id>` si le mode test est actif, sinon `SET @cti_test_user=NULL`.
   - Utilisateur FACTIZY = `$_SESSION['id_admin']` (sans préfixe, même table `users` que l'ERP).
   - Droit à vérifier en base : `users_pages` avec `cle IN ('testeur','testeur_factizy')`, ou id=1.
   - Vérifie d'abord si la session PHP est partagée avec l'ERP (même domaine erp.ctiouest.pro, cookie PHPSESSID) :
     - si oui, lis `$_SESSION['1cti_mode_test']`, pour qu'un seul interrupteur pilote les deux applis ;
     - sinon, fais un interrupteur FACTIZY qui écrit cette même clé.
   - Les liens publics (`document.php` ouvert par un client, `faire_signer.php`, `api_download.php`) n'ont pas de session testeur : ils ne doivent **jamais** être en mode test.
2. **Interface** : bandeau « MODE TEST » bien visible + interrupteur dans le menu FACTIZY, réservés aux utilisateurs qui ont le droit. Même esprit que le pied de page ERP.
3. **Numérotation légale** : les factures et les avoirs ont une numérotation continue obligatoire (`idsuivant` = MAX(id)+1).
   - Une facture de test purgée après la création d'une vraie facture laisse un **trou**. C'est interdit.
   - En mode test : **bloquer** la création de factures et d'avoirs (y compris transformer un devis ou un BC en facture, dupliquer une facture) avec un message clair.
   - Les autres documents (devis, BC, BL, AR…) restent autorisés et marqués.
4. **Neutraliser les effets externes en mode test** :
   - envoi de mails aux clients : forcer vers l'adresse du testeur (mécanisme `$mode_test_mail` existant dans `pages/ajax_envoyer_doc.php`) ;
   - signature électronique ;
   - paiements Mollie ;
   - export comptable / Factur-X transmis ;
   - relances automatiques.
5. **Limite à afficher dans le bandeau** : seuls les `INSERT` sont marqués. Les `UPDATE` et `DELETE` faits sur des données réelles pendant un test ne sont ni tracés ni annulés par la purge.

## Interdits (panne Nextcloud du 25-09-26 causée par le mode test)

- Ne **JAMAIS** toucher aux tables `oc_*` : ni colonnes, ni triggers, ni données.
- Aucune opération en masse générée depuis `information_schema` sans liste blanche `factures_*` / `1cti_*`.
- Pas de `DELETE` / `DROP` / `UPDATE` en masse sur la prod sans confirmation explicite de l'utilisateur.

## Conventions FACTIZY

- Tout en français.
- En-tête de chaque fichier modifié : date + heure + version (`//JJ-MM-AA HH:mm Vx.y`), plus une entrée datée `JJ-MM-AA HH:mm` dans « Liste des modifications faites ». Changelog dans l'en-tête uniquement, **jamais** de `.log` externe pour FACTIZY.
- Le déploiement est automatique (hook, bascule en sudo pour `FACTIZY/FACTIZY`) et les sauvegardes aussi.

## Validation attendue

Une fois les triggers installés par l'utilisateur :

1. activer le mode test, créer un devis → `test_id_user` renseigné sur `factures_devis` et `factures_devis_items` ;
2. désactiver, créer un devis → `NULL` ;
3. essayer de créer une facture en mode test → refus ;
4. purger depuis l'ERP (`?page=mode_test_purge`) → le devis de test disparaît.

Termine par un résumé de ce qui a été modifié, fichier par fichier.